\chapter{Main Goals for the Thesis}
\label{chap:goals}

This thesis focuses on the building of a custom information management system that will aid the day to day operations at PROBE through standardizing and automating processes related to heavy peptides, and centralizing storage of data about these peptides. The need for such a system was uncovered in Chapter~\ref{chap:existingSystem}, and this thesis aims to provide PROBE with a system which will improve the overall efficiency in some of the bottleneck processes their researchers encounter in their work with heavy peptides. Creating a centralized, secure, and efficient way to store data, and making this data quickly and easily available to the researchers at PROBE, plays an important role in the development of this information system. 

In this chapter we describe the main goals outlined for the information system prior to the start of the project. In Section~\ref{sec:standardizing} we have a closer look at why standardizing the processes, workflow, and data is important, before having a look at the requirements regarding the order process in Section~\ref{sec:heavy-peptides}. Section~\ref{sec:security} and Section~\ref{sec:storage} cover the information system's goals on security and storage of data, respectively. We summarize the goals of the information system in Section~\ref{sec:goalsSummary}.

\section{Standardize processes and data}
\label{sec:standardizing}

The current workflow in regard to heavy peptide management at PROBE is not considered optimal, and standardizing the processes concerning heavy peptides is vital to reduce the time spent on heavy peptide management tasks. This can be achieved by standardizing the workflow and automatizing cumbersome and time consuming tasks.

In addition to a standardized workflow, data pertaining to heavy peptides should also be standardized. The system should maintain the integrity of the data, and make sure it is stored on the same format, regardless of where the data stems from and how it was acquired. Gaining access to and manipulating the data should be simple and fast, provided that one is allowed access to the data.

An important aspect that should be taken into account is the prospect to increase efficiency in routine processes when creating an information system. Tasks that take up a lot of time and are repeated often should be automatized. One such task is the creation and management of heavy peptide orders. 

\section{Order heavy peptides}
\label{sec:heavy-peptides}

The system should automate and simplify the cumbersome process of ordering heavy peptides described in Section~\ref{sec:peptideOrders} as much as possible in order to increase efficiency. It should not unnecessarily reproduce functionality provided by other systems.

\subsection{Determine which peptides to order}

Determining which peptides to include in the order is a labor intensive process, but developing a tool to automatically discover peptides that uniquely identify a specific protein, a task currently carried out by utilizing Skyline, is beyond the scope of this thesis. Hence, we will not focus on this step of the order process when developing an information system with the capability of aiding in the process of ordering heavy peptides.

\subsection{Quality control}
\label{sec:goalsQualityControl}

A burdensome task that should be automatized is the quality assurance of the peptides in an order. This task has two different, yet intertwined, conditions that need to be met, and should be easily solved programmatically:

\begin{itemize}
 \item A peptide sequence has to consist of only valid amino acids. As mentioned previously, there are 20 amino acids, each with their own one-letter abbreviation, leaving characters like {\O}, {\AA}, or B invalid amino acid representations (B could represent either Asparagine or Aspartic acid, but ambiguous amino acid representations are not applicable in our case).
 \item The peptide sequences need to conform to certain rules specified by PROBE. These rules ensure that a peptide sequence has certain important properties that make them viable candidates for further exploration in PROBE's research. Examples of such rules are outlined below. 
\end{itemize} 

Depending on the size of the order, ranging from a few tens of sequences (peptides) to upwards of a hundred or more, manually checking each of the sequences for human error as well as verifying that a sequence has or does not have a specific property can be as error-prone as the process of typing in the sequences in the first place. An information system handling this error checking will ensure that orders only include valid peptide sequences conforming to the specified set of rules.

\subsubsection{Rules}
\index{Rules}

Rules are needed in order to ascertain that the peptides have certain properties enabling them to be detected in SRM analysis. Peptides that do not have these properties can not be used for SRM analysis and should thus not be included in an order. Peptide sequences containing amino acids such as M, C, and Q are more viable for modifications. Peptides with modifications are harder to quantify, as one has to target a specific mass when performing SRM experiments. Modified peptides have a different mass than the original peptide and this has to be taken into account when performing SRM experiments on peptides that are viable for modifications. Peptides with several possible cleavage sites are also not desirable. Trypsin cleaves after the amino acids K and R, and sequences containing more than 1 of either of these are not suitable to include in an order.

To aid in the quality assurance of the peptide sequences, there is need for a tool to validate the sequences before submitting them for further processing. As mentioned above, the sequences should be subject to validation according to rules specified by PROBE. The default rule set specified by PROBE is listed below:

\begin{itemize}
 \item Length; minimum 6 and maximum 20 amino acids in a sequence.
 \item Allow K, maximum 1 in a sequence.
 \item Allow R, maximum 1 in a sequence.
 \item Disallow M in sequence.
 \item Disallow C in sequence.
 \item Disallow Q in N-terminal position.
\end{itemize}

The set of rules should not be limited to only the pre-defined rules, nor should they be absolute requirements. This means that it should be possible to define new rules, and it is also desirable to deactivate rules temporarily if sequences should be exempt from one or more rules.

\section{Security}
\label{sec:security}

Security is important when storing, manipulating and making data available. The system should take into account two different types of security measures: authentication and authorization. 

\subsection{Authentication}

Authentication is the mechanism information systems use to identify users in order to allow or disallow access to the system. An authentication system depends on a unique piece of information known or available only to the user being authenticated and the authentication system. A password or a fingerprint are examples of such information. If this information is presented in the correct manner, the user is considered authenticated.

Authenticating users is necessary in order to find out who the user is, and if indeed the user really is who he or she claims to be.

\subsection{Authorization}

While authentication verifies that a user is who he or she claims to be, authorization comes into play after the user has been authenticated. The authorization step is where the application evaluates if the user should be allowed access to a specific resource, and based on the user's access rights, the application either grants or denies access to the resource.

Common problems handled by user authorization is determining whether user A is authorized to access resource R, if user A is authorized to perform operation F, and whether or not user A is authorized to perform an operation F on a specific resource R.

Authentication and authorization are somewhat intertwined concepts - systems where authorization is necessary depend on secure authentication systems to prevent unauthorized users from gaining access to secure resources.

\section{Storage}
\label{sec:storage}

There are three keywords for the storage schema of this information management system, each of which we will elaborate on below:

\begin{itemize}
 \item Central
 \item Long-term
 \item Secure
\end{itemize}

Each keyword is vital to create a reliable storage schema. All three of these keywords go hand in hand with one another when we describe the kind of storage schema we need for our information system.

\paragraph{A central storage solution} In Section~\ref{sec:existingStorage} we learned how data about the heavy peptides has been stored in a non-centralized manner. One of the key qualities that a new information management system should have is that it should store the data in one central location, enabling all of PROBE's employees to access the same information about the heavy peptides at any given time from any given location.

\paragraph{A long-term storage solution} The system should serve as a long-term storage solution for PROBE's heavy peptide data. Spreading files and information across several different computers on several different formats does not add to a long-term, nor a central, storage solution. A new information system should bridge the gaps in the existing storage schema and provide storage that is available for a long period of time without having to worry about loss of data.

\paragraph{A secure storage solution} The authentication and authorization will ensure that data does not fall into the wrong hands by making sure that users only gain access to data they are allowed access to. Another important thing to consider is the potential loss of data. With the system containing important information it is vital that recovery after a data loss or reverting the datasource to an earlier time should data become corrupted is possible. A long-term storage solution should not be vulnerable to data loss, and thus backups should be made at regular intervals.

\section{Summary}
\label{sec:goalsSummary}

In short, the goal for this thesis is to create an information management system for PROBE that will aid PROBE with their research. The system should improve the workflow of procedures currently taking up a lot of the researchers' time, there should be a quality control to reduce manual checking of peptide sequences, concurrently minimizing the chance for human errors. Data should be stored on a standardized format in a secure way. Only authenticated users should be able to access the system, and no user should be allowed access to operations and resources other than what has been authorized for that particular user.